【レポート】ゲームプロダクトに寄り添いながら時代に適用し続けるガードレール型AWS/Google Cloudのクラウドセキュリティ #CEDEC2024 #classmethod_game
2024.09.01こんにちは、ゲームソリューション部の入井です。
今回はCEDEC2024で聴講したセッション『ゲームプロダクトに寄り添いながら時代に適用し続けるガードレール型AWS/Google Cloudのクラウドセキュリティ』についてレポートします。
セッション概要
世の中では脅威が増え、ゲーム開発は複雑化していく中で、発見的統制・予防的統制を駆使して柔軟に強化しているアカツキゲームスのAWSとGoogle Cloudのクラウドセキュリティについて紹介します。
クラウドセキュリティのインシデントの多くは設定ミスが原因です。ミスは起こるものとして捉え、仕組みで解決していくことが大切になります。
そのため、アカツキゲームスでは毎日20,000以上のリソースの監査を行って設定ミスによるインシデントを未然に防いでいます。そのアーキテクチャと得られた知見をお話します。さらに長年の運用で見えてきた課題や最近のAWSサービスアップデートを元にアーキテクチャの再構築を行ったので、その内容にも触れます。
また、セキュリティアラートでプロダクトが疲弊してしまわないなど、運用で工夫している点も紹介します。
※CEDEC2024セッションページより引用
印象に残った点
クラウドセキュリティの脅威
昨今、AWSやGoogle Cloud、Azureといったパブリッククラウド上で運用しているシステムは、パブリッククラウドのシェア拡大と比例して攻撃者のターゲットにされやすくなっています。
CSA（Cloud Security Alliance）の調査結果を基にクラウドにおける脅威のランキングが紹介され、その中では鍵の管理ミスやセキュアで無いAPI、設定ミスなどシステム管理者側でコントロール可能な『内部要因』が脅威の上位を占めています。一方、コントロールのできない『外部要因』では、システムの脆弱性やサードパーティのリリースがセキュアで無いなどの脅威がランクとして高く、組織的な犯罪など悪意のある攻撃による脅威はそれらよりランクが下なのが印象的でした。
セキュリティ統制の考え方
クラウドセキュリティの具体的な統制の仕組みとしては、予防的統制（ゲートキーパー） と 発見的統制（ガードレール） の2種類があります。
ゲートキーパーは、許可したリソースや操作のみを通す仕組みで、ルールによって認められていないことをしっかり通さないことができますが、チェックする側・される側の工数がかかるというデメリットがあります。
ガードレールは、作成されたリソースをルールに基づいてチェックし、ルールが守れていないものがあればアラート等で知らせ、修正を推奨するという仕組みです。チェック関係の工数は最低限となりますが、セキュリティ的に致命的なミスが放置される可能性を潰しきれないというデメリットがあります。
これら2つの統制方法は一長一短があるため、どちらかを利用するということでなく、適切に組み合わせることでセキュリティ強度を維持しつつ工数も最小限にすることができます。
今回の講演では、ゲートキーパーの仕組みでガードレールだけでは致命的になる操作を防ぎ、その他はガードレールで対処する方法の提案がありました。ガードレールの仕組みの具体的な方法としては、CSPMによる設定ミス監査や、脅威や脆弱性を検知することなどが紹介されました。
AWSで構築するCSPM
アカツキゲームス社では、AWSとGoogle Cloud上に多くのゲームプロダクト関連リソースやゲーム基盤などがあり、クラウドが侵害された場合の経営インパクトが大きいことからクラウドセキュリティに力を入れているとのことです。
具体的にどのような仕組みが作成されているかについてはいくつか紹介があり、この記事ではその中からCSPMについての部分を書いていきます。
まず、当初CSPMの仕組みははAWS Cloudformation StackSetsとAWS Configで構成されていました。AWS Cloudformation StackSetsは、AWS Configのリソースを全てのAWSアカウント・リージョンにデプロイするために使用しています。AWS Configでは、標準で使用できるマネージドルールの他、Lambdaによるカスタムルールが使用されています。
ただ、実際に運用を続けていたところ、いくつかの課題が生じました。
利用者の目線では、CSPMアラートの優先度情報が無いことが原因で重要な対応が後手に回ってしまう可能性が生じたり、Slackで通知したアラート情報が流れてしまうと現在どれだけ対応が必要なのかが分からなくなる、といった課題がありました。
セキュリティ管理者の目線では、アカウントやリージョンをまたいだ全ての検出結果を一覧するビューが無いことや、運用上あえてルールを破っている場合の通知を無くすための例外対応が複雑化した、といった課題がありました。
これらの課題に対応するため導入されたのがAWS Security Hubでした。
AWS Security Hubでは、AWS ConfigやGuard Dutyといったセキュリティ関係のサービスで検出されたアラートを集約して見ることができます。
Security Hubでは、検出結果に優先度ラベルが自動的に付与されるため、優先度についての課題は解決できました。また、マルチアカウント・マルチリージョンで検出結果を集約できるため、管理対象の全ての検出結果を一覧で見ることが可能になります。
例外対応については、Automationという機能で検出アラートについて特定の条件の時は解決済にする、というような設定が可能なため、SecurityHubに集約することができました。
GoogleCloudでのCSPM
AWSと平行で使用しているGoogleCloud上でもCSPMの仕組みが構築されています。
脅威検出については、AWSのSecurity Hubと似た機能であるSecurity Command Center(SCC)が使われています。
例外登録については、SCCのミュートルールで実現しています。
感想
パブリッククラウドを使うことでゲームのサーバーやストレージ等を手軽に構築可能になりますが、セッションの中でも言われているように、クラウドの利用が広がると共に攻撃者に狙い撃ちにされる可能性が高くなっています。セキュリティに関わる設定ミスによる抜け穴があると、狙われた時になすすべも無く攻撃を受けることになるため、今回の講演で紹介されている仕組み等を有効活用し、せめて自社でコントロール可能な脅威要因だけは塞いでおくことが重要と思います。
